My R Timeline

• Digital agencies since 2007
• useR since 2012 - Motive: how to use all this web data?
• Shiny enthusiast e.g. https://gallery.shinyapps.io/ga-effect/
• Google Developer Expert - Google Analytics & Google Cloud
• Several Google API themed packages on CRAN via googleAuthR
• Part of cloudyr group (AWS/Azure/GCP R packages for the cloud) https://cloudyr.github.io/
• Now: Data Engineer @ IIH Nordic

GA Effect

googleAuthRverse

• searchConsoleR
• googleAuthR
• googleAnalyticsR
• googleComputeEngineR (cloudyr)
  
• bigQueryR (cloudyr)
• googleCloudStorageR (cloudyr)
• googleLanguageR (rOpenSci)

Slack group to talk around the packages #googleAuthRverse

Dockerfiles from The Rocker Project

https://www.rocker-project.org/

Maintain useful R images

• rocker/r-ver
• rocker/rstudio
• rocker/tidyverse
• rocker/shiny
• rocker/ml-gpu

Thanks to Rocker Team

Dockerfiles

FROM rocker/tidyverse:3.6.0
MAINTAINER Mark Edmondson (r@sunholo.com)

# install R package dependencies
RUN apt-get update && apt-get install -y \
    libssl-dev 

## Install packages from CRAN
RUN install2.r --error \ 
    -r 'http://cran.rstudio.com' \
    googleAuthR \ 
    googleComputeEngineR \ 
    googleAnalyticsR \ 
    searchConsoleR \ 
    googleCloudStorageR \
    bigQueryR \ 
    ## install Github packages
    && installGithub.r MarkEdmondson1234/youtubeAnalyticsR \
    ## clean up
    && rm -rf /tmp/downloaded_packages/ /tmp/*.rds \

Docker + R = R in Production

• Flexible No need to ask IT to install R places, use docker run; across cloud platforms; ascendent tech

• Version controlled No worries new package releases will break code

• Scalable Run multiple Docker containers at once, fits into event-driven, stateless serverless future

Creating Docker images with Cloud Build

Continuous development with GitHub pushes

Images versioned in private repository

Strategies to scale R

• Vertical scaling - increase the size and power of one machine
• Horizontal scaling - split up your problem into lots of little machines
• Serverless scaling - send your code + data into cloud and let them sort out how many machines

Bigger boat

Bigger VMs

Good for one-off workloads

Pros

Probably run the same code with no changes needed
Easy to setup

Cons

Expensive
May be better to have data in database

Launching a monster VM in the cloud

3.75TB of RAM: $423 a day (compare ~$1 a day for standard tier VM)

library(googleComputeEngineR)

# this will cost a lot
bigmem <- gce_vm("big-mem", 
                 template = "rstudio", 
                 predefined_type = "n1-ultramem-160")

RStudio Server

Standard VM serving Shiny

library(googleComputeEngineR)

# your customised Docker image built via Build Triggers
custom_image <- gce_tag_container("custom-shiny-app", 
                                  "your-project")
## make new Shiny template VM for your self-contained Shiny app
vm <- gce_vm("myapp", 
             template = "shiny",
             predefined_type = "n1-standard-2",
             dynamic_image = custom_image)

Cloud computing considerations

• Only charged for uptime, can configure lots of VMs so…
• Have lots of specialised VMs (Docker images) not one big workstation
• Keep code and data separate e.g. googleCloudStorageR or bigQueryR
• Consider VMs as like functions of computing power

Lots of little machines can accomplish great things

Parellise your code

Good for parallelisable or scheduled data tasks

Pros

Fault redundency
Forces repeatable/reproducable infrastructure
library(future) makes parallel processing very useable

Cons

Changes to your code for split-map-reduce
Write meta code to handle I/O data and code
Not applicable to some problems

Adopt a split-map-reduce mindset

• Break problems down into stateless lumps
• Reuseable bricks that can be applied to other tasks

Setup a cluster

New in googleComputeEngineR v0.3 - shortcut that launches cluster, checks authentication for you

library(googleComputeEngineR)

vms <- gce_vm_cluster()
#2019-03-29 23:24:54> # Creating cluster with these arguments:template = r-base,dynamic_image = rocker/r-parallel,wait = 
#FALSE,predefined_type = n1-standard-1
#2019-03-29 23:25:10> Operation running...
...
#2019-03-29 23:25:25> r-cluster-1 VM running
#2019-03-29 23:25:27> r-cluster-2 VM running
#2019-03-29 23:25:29> r-cluster-3 VM running
...
#2019-03-29 23:25:53> # Testing cluster:
r-cluster-1 ssh working
r-cluster-2 ssh working
r-cluster-3 ssh working

library(future)

googleComputeEngineR has custom method for future::as.cluster

## make a future cluster
library(future)
library(googleComputeEngineR)

vms <- gce_vm_cluster()
plan(cluster, workers = as.cluster(vms))

...do parallel...

Forecasting example

# create cluster
vms <- gce_vm_cluster("r-vm", cluster_size = 3)
plan(cluster, workers = as.cluster(vms))

# get data                          
my_files <- list.files("myfolder")
my_data <- lapply(my_files, read.csv)

# forecast data in cluster
library(forecast)
cluster_f <- function(my_data, args = 4){
   forecast(auto.arima(ts(my_data, frequency = args)))
}

result <- future_lapply(my_data, cluster_f, args = 4) 

Multi-layer future loops

Can multi-layer future loops (use each CPU within each VM)

Thanks for Grant McDermott for figuring optimal method (Issue #129)

future_sim <- 
  ## Outer future_lapply() call loops over the no. of VMS
  future_lapply(1:length(vms), FUN = function(x) { 
  
    ## Inner future_lapply() call loops over desired no. of iterations / no. of VMs
    future_lapply(1:(iters/length(vms)), FUN = slow_func) 
    
  })

CPU utilization

3 VMs, 8 CPUs each = 24 threads (~$3 a day)

We spoke previously of

Clusters of VMs + Docker = Horizontal scaling

Kubernetes

Clusters of VMs + Docker + Task controller = Kubernetes

Kubernetes

Good for Shiny / R APIs

Pros

Auto-scaling, task queues etc.
Scale to billions
Potentially cheaper
May already have cluster in your organisation

Cons

Needs stateless, idempotent workflows
Message broker?
Minimum 3 VMs

Dockerfiles for Shiny apps

Built on Cloud Build upon GitHub push

FROM rocker/shiny
MAINTAINER Mark Edmondson (r@sunholo.com)

# install R package dependencies
RUN apt-get update && apt-get install -y \
    libssl-dev
    
## Install packages from CRAN needed for your app
RUN install2.r --error \ 
    -r 'http://cran.rstudio.com' \
    googleAuthR \
    googleAnalyticsR

## assume shiny app is in build folder /shiny
COPY ./shiny/ /srv/shiny-server/myapp/

Kubernetes deployments - Shiny

kubectl run shiny1 \
  --image gcr.io/gcer-public/shiny-googleauthrdemo:prod \
  --port 3838

kubectl expose deployment shiny1 \
  --target-port=3838  --type=NodePort

Dockerfiles for plumber APIs

Built on Cloud Buid every GitHub push:

FROM trestletech/plumber

# copy your plumbed R script     
COPY api.R /api.R

# default is to run the plumbed script
CMD ["api.R"]

Kubernetes deployments - Plumber API

kubectl run my-plumber \
  --image gcr.io/your-project/my-plumber:prod \
  --port 8000

kubectl expose deployment my-plumber \
  --target-port=8000  --type=NodePort

Shiny apps waiting for service

Expose your workloads via Ingress

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: r-ingress-nginx
spec:
  rules:
  - http:
      paths:
      - path: /gar/
      # app deployed to /gar/shiny/
        backend:
          serviceName: shiny1
          servicePort: 3838

Apps available at URL on demand

curl 'http://mydomain.com/api/echo?msg="its alive!"'
#> "The message is: its alive!"

GoogleNext19 - Data Science at Scale with R on GCP

A 40 mins talk at Google Next19 with lots of new things to try!

https://www.youtube.com/watch?v=XpNVixSN-Mg&feature=youtu.be

New concepts

Great video that goes more into Spark clusters, Jupyter notebooks, training using ML Engine and scaling using Seldon on Kubernetes that I haven’t tried yet

Some shots from the video

Google Cloud Platform - Serverless Pyramid

Google Cloud Platform - R applications

Take-aways

• Anything scales on Google Cloud Platform, including R
• Docker docker docker
• library(future)
• Pick scaling stategy most suitable for you

Gratitude

• Thank you for listening
• Thanks to Kenneth for inviting me
• Thanks to RStudio for all their cool things. Support them by buying their stuff.
• Thanks again to Rocker
• Thanks to Google for Developer Expert programme and building cool stuff.

Say hello afterwards

• @HoloMarkeD
• https://code.markedmondson.me
• Contact us at IIH Nordic to build scale for you mark@iihnordic.com